1. Field of the Invention
The present invention relates generally to data processing environments and, more particularly, to a system providing methodology for migration of databases between platforms having different byte storage architectures.
2. Description of the Background Art
Computers are very powerful tools for storing and providing access to vast amounts of information. Computer databases are a common mechanism for storing information on computer systems while providing easy access to users. A typical database is an organized collection of related information stored as “records” having “fields” of information. As an example, a database of employees may have a record for each employee where each record contains fields designating specifics about the employee, such as name, home address, salary, and the like.
Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, a database management system or DBMS is typically provided as a software cushion or layer. In essence, the DBMS shields the database user from knowing or even caring about the underlying hardware-level details. Typically, all requests from users for access to the data are processed by the DBMS. For example, information may be added or removed from data files, information retrieved from or updated in such files, and so forth, all without user knowledge of the underlying system implementation. In this manner, the DBMS provides users with a conceptual view of the database that is removed from the hardware level. The general construction and operation of database management systems is well known in the art. See e.g., Date, C., “An Introduction to Database Systems, Seventh Edition”, Part I (especially Chapters 1-4), Addison Wesley, 2000.
Database systems have been in broad use for a number of years performing various types of applications on a wide range of computer hardware platforms. In this type of heterogeneous environment, users of database systems frequently have a need to migrate existing databases from one platform to another. For example, in recent years computer systems running the Linux operating system have become more widely used, and many database users are interested in migrating their existing databases to new Linux platforms. Database management systems typically include archive functionality enabling a user to save the data from the database to an archive system or device, such as tape. The archive can be used to restore the database (e.g., in the event the database is corrupted or damaged). This archive functionality can also be used for purposes of migrating a database from a first or “source” machine to a second or “target” machine (e.g., in the event the user wants to change the machine on which the database is used).
If the hardware platform and operating system of the source and target machines are the same, a physical backup mechanism can be used for migrating the data to the target machine. In this case, the user can simply make a backup or archive of the database on the source machine and load this archive onto the target machine using standard database commands. For example, a database DUMP command can be used on source platform to store the database in an archive and a database LOAD command can be used to load the database on the target platform from the archive. Dump and load operations are physical database back-up operations in a database system which can be used to move a database from one machine to another. However, if the architecture of the source and target platforms differ, it may not be possible to use this type of physical backup mechanism.
Some computers, such as IBM mainframes and Sun Solaris machines, have a “big-endian” byte storage architecture, while many other computers, including PCs and Linux platforms, use a “little-endian” byte storage architecture. A few computer systems are bi-endian in that they can understand both systems. The terms “big-endian” and “little-endian” refer to which bytes are most significant in multi-byte data types and describe the order in which a sequence of bytes is stored in a computer's memory. In a big-endian system, the most significant value in the sequence is stored at the lowest storage address (i.e., first). In a little-endian system, the least significant value in the sequence is stored first. For example, consider the number 1025 (2 to the tenth power plus one) stored in a 4-byte integer: 00000000 00000000 00000100 00000001.
The big-endian representation of 1025 is as follows:    Address 00: 00000000    Address 01: 00000000    Address 02: 00000100    Address 03: 00000001
The little-endian representation of 1025 is as follows:    Address 00: 00000001    Address 01: 00000100    Address 02: 00000000    Address 03: 00000000
Note that the example above shows only big- and little-endian byte orders. The bit ordering within each byte can also be big- or little-endian, and some architectures actually use big-endian ordering for bits and little-endian ordering for bytes, or vice versa. Converting data between the big-endian and little-endian systems is sometimes referred to as the “NUXI” problem. Imagine the word UNIX stored in two 2-byte words. In a big-endian system, it would be stored as UNIX. However, in a little-endian system, it would be stored as NUXI.
Currently, a user wanting to migrate a database from a big-endian platform (e.g., Solaris) to a little-endian platform (e.g., Linux) cannot use the above-described physical back-up mechanism because of incompatibilities between the byte storage format of the two platforms. The same limitation is also applicable to migration of a database from a little-endian platform to a big-endian platform. A user wishing to migrate a database between a source platform and a target platform having different endian types currently must do so using logical backup mechanisms. Logical backup mechanisms generally require the user to issue commands for each table in the database, which is a particularly lengthy and tedious operation if the database is large and has numerous tables (e.g., 10,000 tables). Also, the user must recreate the database schema on the target platform as well as recreate stored procedures and so forth. As a result, the process of migrating a database using a logical backup mechanism is very slow.
Some database systems include tools and utilities that may assist a user in logical backup operations. For example, Sybase® Adaptive Server® Enterprise (ASE) includes a bulk copy (bcp) utility that can automate portions of this logical backup process. However, these tools and utilities do not fully automate the process and the user still must define the format of the backup files. For example, migration of a database using a bcp-out/bcp-in method requires an export/import operation to be done for each table in the database. Also, users are required to recreate the database schema on the target platform (i.e., create table SQL command, etc.). As a result, performing a database migration using these tools remains a slow and tedious process that typically requires many hours or several days to complete. Moreover, users cannot access the data in the database during this migration process. All told, this current logical backup approach for moving a database from one platform to another where endian type is different is very cumbersome and complicated for users. It is also a very slow process that disrupts normal system operations.
What is needed is a solution that will allow users to more easily and quickly migrate databases between platforms having a different underlying byte storage architecture (endian type). The solution should automate the migration process so that a user of a database system could simply load an archive file that was generated on a machine having a different byte-order. Ideally, the solution should also migrate the database's schema and its stored procedures to the target platform so that the user is not required to recreate the database's schema and stored procedures on the target platform. The present invention provides a solution for these and other needs.